---title: "Transcrição da Prova Teórica 1 — nome: " disciplina: "Gestão de Projetos de Software" codigo_disciplina: "GPS" avaliacao: "Prova Teórica 1" periodo: "2026-2" data: "2026-10-19" discente: nome: "Evelyze Pinheiro dos Reis" matricula: "20213012374" curso: "Engenharia de Computação" turma: "Unidade Timóteo" nota_total: 19.2 nota_maxima: 25.0 legibilidade_percentual: 90 metadados_transcricao: transcritor: "Antigravity Assistant (Visão Computacional)" data_transcricao: "2026-10-19" grau_fidelidade: "Fiel (ipsis litteris), preservando rasuras e omissões" format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Transcrição da Prova Teórica 1 — Evelyze Pinheiro dos Reis ## Questão 1 ### 1.1 (1,5) Projeto vs. operação — três características com evidências: O Professor Agente é um projeto porque ele tem começo, meio e fim, ele é desenvolvido durante o período de duração da disciplina, não sofre manutenção após ela terminar, é realizado com 4 sprints apenas. ### 1.2 (2,0) Duas alternativas de trade-off sem sacrificar qualidade + impacto no Triângulo de Ferro: Reduzir testes automatizados de CI/CD sacrificam a qualidade, reduzindo o escopo para manter o prazo de entrega e custo. Redução do escopo definido no Project Charter entregando um produto viável mínimo para manter o tempo de entrega e o custo. ### 1.3 (1,5) Ciclo de vida e justificativa (preditiva, ágil ou híbrida): O ciclo de vida adotado e abordagem é ágil, porque a cada feitura de uma funcionalidade, é feito a verificação do código, testes e manutenção em um ciclo duradouro. --- ## Questão 2 ### 2.1 (1,5) EAP de dois níveis (substantivos, regra dos 100%, $\ge 3$ pacotes de trabalho): ``` 1) Construção das documentações 2) Readme.md EAP.md } Pacotes de trabalho Riscos.md ``` A EAP é hierárquica porque possui níveis: um é geral e o outro é mais específico, cada nível 2 constituíra uma issue (pacote de trabalho) que deverá ter um prazo de entrega curto. ### 2.2 (2,0) Duas issues completas no GitLab: **Título:** Atualização do documento Readme.md **Descrição:** Documento que contém toda a descrição de como rodar o software. **Critério de aceitação:** informativo e autoexplicável. **Estimativa de tempo:** 1 dia **Título:** Criação do documento EAP.md **Estimativa de tempo:** 2 dias *Justificativa da diferença:* O tempo é diferente para os dois porque para fazer a EAP precisa-se de que o time interaja e defina a estrutura que o software terá. ### 2.3 (1,5) Milestones vs. Sprints + quando Kanban é mais adequado: Milestones não substituem sprints, uma vez que milestone é relacionado a tempo de calendário e a sprint está relacionada à execução de uma tarefa. Kanban sem sprints pode ser adequado apenas quando se quer definir o início e o término de um projeto. --- ## Questão 3 ### 3.1 (1,5) DoD vs. DoR — critérios objetivos e garantia de qualidade: O DoD é um conceito transversal que se relaciona ao projeto/repositório, após passarem em todos os testes, inclusive de CI/CD e estarem prontos. A funcionalidade de chat não está pronta se os testes de segurança forem omitidos porque pode esconder um bug que pode ser descoberto quando chegar ao cliente. ### 3.2 (1,5) Classificação dos quatro custos da qualidade (PAF): a) prevenção b) avaliação c) falha externa d) falha interna. O custo da falha externa tende a ser mais alto porque denigre a imagem da empresa, exige manutenção no código após o bug ser encontrado pelo cliente. ### 3.3 (2,0) Regra 1-10-100 (custo de correção) aplicada a LLMs: O custo de achar um erro durante a fase de prevenção é 1. Já quando é descoberto na avaliação ou falha interna é 10. Quando o erro é uma falha externa o custo é 100. Em projetos de software com IA, os erros são comumente encontrados na avaliação/falha interna, porém como a LLM pode apresentar limite de tokens, erros podem ser encontrados como falha externa. A avaliação deve fazer testes de segurança de forma a garantir que o software funcione. --- ## Questão 4 ### 4.1 (1,5) Risco vs. problema (Cap. 6) + quadrante na matriz P$\times$I e estratégia de resposta: ``` [Espaço para desenho/diagrama da Matriz PxI] Marcado "X" no quadrante inferior direito (Médio Impacto / Baixa Probabilidade) ``` Era um problema porque está relacionado ao passado, já ocorreu. O risco antes do vazamento possui baixa probabilidade e alto impacto porque depende do programador, mas impacta em muito a empresa. Estratégia: renovar a chave de API. ### 4.2 (1,5) Três ações imediatas + uma ação preventiva (defesa em profundidade): Resetar a chave da API, retirar do histórico de commit com a chave, revisar a configuração do software colocando a chave como item a ser ignorado no .gitignore. ### 4.3 (2,0) Risco de entrada modelado (causa, P, I, mitigação, contingência) + mitigação de saída + artefato de documentação: Risco de entrada: prompt injection. Causa: usuário coloca instrução como se fosse do sistema. Probabilidade: alta. Impacto: a LLM pode responder apresentando código. Mitigação: colocar uma possibilidade de um system prompt. Para o risco de saída de alucinação pedagógica, colocar no system prompt que não consegue responder aquilo no momento. Deve-se documentar em ADR por se tratar de um documento curto com as principais decisões do time. --- ## Questão 5 ### 5.1 (1,5) Comunicação síncrona vs. assíncrona no GitLab + prática/ritual de registro de decisões: Síncrona: permite desenrolar algo que está travando o trabalho da equipe. Assíncrona: permite deixar documentado as principais decisões do time para consulta posterior (rastreabilidade). As decisões técnicas críticas devem ser registradas no GitLab como issues, comentários porque elas permitem ser consultadas posteriormente e vira um consenso para toda a equipe. ### 5.2 (1,5) Matriz Poder $\times$ Interesse dos 5 stakeholders, premissas e estratégia de comunicação: ``` [Espaço para desenho/diagrama da Matriz Poder x Interesse] - Manter satisfeito: 4 (Provedor da API) - Gerenciar de perto: 2, 3 (Professor e Equipe de desenvolvimento) - Monitorar: 1 (Alunos) - Manter informado: 5 (Coordenação) ``` O professor e a equipe de desenvolvimento possuem alto poder e alto interesse porque querem o software em funcionamento. Para eles, sugere-se reuniões diárias via Teams, canal de mensagens via Telegram que permite salvar o histórico de mensagens para novos usuários. ### 5.3 (2,0) Conflito pedagógico vs. técnico — Thomas-Kilmann (1 escolha justificada + 2 inadequadas): Seriam necessários respostas curtas por meio do chat da LLM com perguntas socráticas, para não dar resposta pronta para o aluno e direcioná-lo para resolução do exercício, orientando-o. Seria inadequado uso de frases longas pelo chat, uma vez que a resposta poderia ser redundante, como também o fornecimento de soluções para o problema apresentado.